home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000112_icon-group-sender _Tue Dec 8 13:08:05 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  2KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA01594
  4.     for icon-group-addresses; Tue, 8 Dec 1998 13:07:54 -0700 (MST)
  5. Message-Id: <199812082007.NAA01594@baskerville.CS.Arizona.EDU>
  6. Date: Tue, 8 Dec 1998 10:30:57 -0700
  7. From: swampler@noao.edu (Steve Wampler)
  8. Subject: Re: Past Keyword / Coexpr Help
  9. To: icon-group@optima.CS.Arizona.EDU
  10. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  11. Status: RO
  12.  
  13.  
  14.  
  15. MJE wrote:
  16. > 
  17. > 
  18. > What everyone is missing about procedures-that-do-the-job is the speed
  19. > consideration.  Think about embedding either procedure in a deep inner
  20. > loop of some kind.  At that point, it is much preferable to have a
  21. > keyword, which
  22. > 
  23. > (a) avoids any overhead of procedure calling, (b) doesn't have to both
  24. > find and then match the same text (redundancy), (c) simplifies the code
  25. > readability
  26. > 
  27. > So with Clint I must say that the keyword is still a good idea.
  28. > 
  29. > Thanks for the advice however, it gets me off the dime.
  30.  
  31. Uh, you don't mean a keyword, you mean a 'built-in' function.  You still
  32. have the overhead of procedure calling - there is no difference in the
  33. call to a user-supplied procedure and a built-in.  You do gain some
  34. improvement by implementing past() in C (as a built-in), but you may be
  35. surprised at how small that improvement really is!  (There are likely to
  36. be other factors that dominant the overall time.)
  37.  
  38. Also, Nevin's solution avoids the redundant match, and either solution
  39. is called in exactly the same way as a built-in past() would be, so the
  40. code readability can't be much different.
  41.  
  42. What might be nice is to develop an IPL 'pack' of useful string analysis
  43. procedures, then see which ones might be considered candidates for
  44. speed improvements by recoding in C - after gaining experience with their
  45. use.
  46.  
  47. --
  48. Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)]
  49. The gods that smiled at your birth are now laughing openly. (Fortune Cookie)
  50.